home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19980901-19981211 / 000220_news@newsmaster….columbia.edu _Tue Oct 27 10:41:42 1998.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id KAA11577
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Tue, 27 Oct 1998 10:41:42 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id KAA07249
  7.     for kermit.misc@watsun; Tue, 27 Oct 1998 10:41:41 -0500 (EST)
  8. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Q. about running kermit over a proprietary transmission network
  12. Date: 27 Oct 1998 15:41:38 GMT
  13. Organization: Columbia University
  14. Lines: 91
  15. Message-ID: <714pji$b9b$1@apakabar.cc.columbia.edu>
  16. References: <713hfu$3na$1@nnrp1.dejanews.com>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:9420
  19.  
  20. In article <713hfu$3na$1@nnrp1.dejanews.com>,
  21.  <tony_w_k_wu@my-dejanews.com> wrote:
  22. : I want to run kermit over 57600 baud async. serial through a
  23. : proprietary transmission system/network and comes out serially
  24. : into another device. The typical transfer file size are
  25. : about 300Kbyte. (up to 1 -2 Mbyte max)
  26. : 
  27. : The proprietary transmission system is a CSMA/CD kind of LAN.
  28. : Its speed is around 44Kbaud and it is NOT noisy.
  29. : Note: the proprietary transmission system is about 10-20%
  30. : slower than the serial link.
  31. : It support :
  32. : a) UNACK type of transmission of data packet with 88bytes data
  33. :    payload. (quick and no guarantee of delivery)
  34. :    latency is about 40 ms per 88bytes data packet.
  35. : 
  36. : b) ACK type of transmission with segmentation/reassembly capability
  37. :    and arbitrary data length. (guarantee delivery)
  38. : 
  39. : I need to build some software in the proprietary transmission system
  40. : to convert the kermit over serial into
  41. : either a) or b) type of transmission format. (or even combination of
  42. : both)
  43. : 
  44. : Note: there is no HW flow control ie RTS/CTS between the serial
  45. :       link
  46. : Note: XON and XOFF is delivered transparently to the target device.
  47. : 
  48. : Original thought is to build something extremely simple base on
  49. : a) type of transmission.
  50. : With a scheme like the follow:
  51. :    send a packet if I receive 88bytes serially or I have not
  52. :    send a packet in last 20ms and send whatever number of bytes
  53. :    I have received.
  54. : 
  55. : Alternatively,
  56. :    I can look at the kermit initialization and negotiation sequence
  57. :    to figure out the packet length, window size. Look for the ^A and
  58. :    EOL to delimit each packet. And pack each kermit packet into
  59. :    type a) or type b) transmission adaptively. e.g. ACK/NAK kermit packet
  60. :    on type a) and data packet on type b).
  61. : 
  62. : What do you think about the 2 schemes? Would I be able to gain any throughput
  63. : improvement with the alternative scheme? How would you configure the window
  64. : size and packet size in kermit to maximize throughput? Any thing I should
  65. : take special care of when I am building something described above? Any other
  66. : ideas to get the max througput?
  67. : 
  68. You didn't say what the two end systems are.  Let's assume they are two
  69. computers capable of running relatively modern (i.e. tunable) Kermit versions.
  70.  
  71. Transmission type (a) is like an IP datagram; type (b) is like a TCP packet.
  72. Kermit will work with either one, but if you want to use type (a) then, yes,
  73. you should ensure that the Kermit packet fits in the 88-byte LAN packet.
  74. This would, of course, result in rather slow transfers.  You can improve the
  75. efficiency by choosing a Kermit window size greater than 1 (whatever works
  76. best, up to 31 or so).  Kermit itself will handle resequencing, recovery of
  77. lost packets, etc.
  78.  
  79. But unless there is some compelling reason not to use the guaranteed delivery
  80. method (type (b) above), I would recommend that.  In that case, you should
  81. be free to set the packet and windows sizes to any combination at all that
  82. gives good performance.
  83.  
  84. >From your description, it seems the most serious problem comes from lack
  85. of flow control between the LAN and the computer.  You say:
  86.  
  87. : Its speed is around 44Kbaud and it is NOT noisy.
  88. : Note: the proprietary transmission system is about 10-20%
  89. : slower than the serial link.
  90.  
  91. and:
  92.  
  93. : Note: there is no HW flow control ie RTS/CTS between the serial link
  94. : Note: XON and XOFF is delivered transparently to the target device.
  95.  
  96. If this is true, then what prevents the computer from overrunning the LAN
  97. when sending data into it?  End-to-end flow control will not help very much
  98. in this situation, since it is not the target system that is being overrun.
  99.  
  100. In the absence of effective flow control between the computer and the LAN,
  101. the only ways to prevent data loss are:
  102.  
  103.  1. Set the serial speed of the sending computer below that of the LAN,
  104.     and of the receiving computer *higher* than that of the LAN.  This
  105.     is obviously inconvenient, but will allow the highest transfer rates.
  106.  
  107.  2. Reduce the Kermit packet and/or window sizes to values that minimuze
  108.     overruns and maximize throughput.
  109.  
  110. - Frank